You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Building opcache into the main executable breaks opcache.huge_code_pages, as we were relying on the fact that accel_remap_huge_pages() is not in the same mapping as the main text segment.
The reason will be displayed to describe this comment to others. Learn more.
I understood your changes in accel_remap_huge_pages(). They are fine.
I didn't completely understand the reason of changes in accel_find_program_section().
What is the problem with the original version?
I don't care a lot, I just like to know.
I made this change because /proc/self/maps reflects program segments, not sections. Each segment may contain multiple sections. The segment / memory mapping containing the .text section may also contains .plt, .init, .fini, as well as the section where I placed accel_remap_huge_pages (.remap_stub), and other unspecified sections.
accel_find_program_section() finds the exact start/end of the .text section only.
accel_find_program_section() finds the exact start/end of the .text section only.
OK.
Will it miss read-only data section? I'm not sure how it's represented in Elf. Original version remapped it to huge-pages together with .text out of the box.
I understood why you need this :) - to exclude .remap_stub.
Yes :) This also avoids problems when accel_remap_huge_pages() calls code from other sections, such as .plt.
accel_find_program_section() finds the exact start/end of the .text section only.
OK. Will it miss read-only data section? I'm not sure how it's represented in Elf. Original version remapped it to huge-pages together with .text out of the box.
Oh, I didn't notice that. I will check if I can also remap the ro data section.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Building opcache into the main executable breaks
opcache.huge_code_pages, as we were relying on the fact thataccel_remap_huge_pages()is not in the same mapping as the main text segment.Here I ensure that
accel_remap_huge_pages()is placed out of the text segment, and remap only the text segment. This approach is used in https://github.com/intel/iodlr/blob/676bb7dec378d561e4d900fbdaed6ce8dbe449a1/large_page-c/large_page.c#L260.This should work on the same systems supported by the original
opcache.huge_code_pagesimplementation (Linux and FreeBSD).I've also tried using mremap() in #19379, but it's not supported on FreeBSD. We could still use the mremap() approach on Linux.
Windows failure unrelated.